Development Time Line
This page is meant to be a living document that describes current thinking for what we want to do with Icarus Verilog development. We try to divide our intentions into a release schedule of sorts. Note that there are no dates. It'll be ready when it's ready. The Release Process The release process for Icarus Verilog takes place in the git repository, and is managed by branches and tags. Snapshots Snapshots are tagged points on the master branch. Snapshot tags have the form sYYYYMMDD where YYYY is the year, MM the numeric month and DD the day. Keeping to this format for snapshot tags makes them easy to recognize. Release Candidates A release comes to existence as a branch in the git repository, so that all development on the master branch does not go into the release branch by default. A new branch format v0_X-branch starts the release candidates for the 0.X release series. Initially, there are no release tags on a release branch, and the release isn't really released yet. This is a release candidate branch. The actual candidates are managed in an ad hoc manner up to the first actual release. There may be non-release tags to mark potential releases. Thus we create the branch for the release and put it into a feature freeze. We then have time to polish it up for the first proper release on the branch, and the master can in the mean time continue on with new development. Released Releases The first release will be tagged v0_X_1 for release 0.X.1 and marks the end of the release candidate phase. The next release will be tagged v0_X_2 for release 0.X.2, and so forth. Release tags all have the same format. We start the releases as .1 to leave .0 for the first release candidates. Unscheduled but Planned Tasks Rework the way nets are represented in vvp Currently, nets visible to vpi are implemented as functors that receive propagations from their connection point in the net list of the elaborated design. This usually works, but there are some problems: * vpi_put_value puts values into the net, but those values don't get propagated. * force/release of nets tends to not work for the same reason that vpi_put_value doesn't work. Also, those nodes for nets are wasteful as the scheduler has to propagate the data into them. The difficulty is that nets have characteristics, such as forced state and assigned callbacks that we really don't need to include in every vvp_net_t object. This should probably wait for after the 0.9 release. Version 0.8.7 I think we want this to be the last 0.8 release. It should only be minor bug fixes. The consensus, I think, is that 0.8 should be retired except for simulation purposes as soon as 0.9 is released. We may want to keep it around for synthesis support, but in that case we'll want 0.8.7 to be able to install on a system that already has a 0.9 install, and not conflict. Prerequisites for this release: * Support for install suffix. Done We want 0.8.7 to be able to co-exist with current releases. The default starting at 0.8.7 should be to include the suffix. This is done, except that we want to fix up the aclocal and the verilog.spec for 0.8 to make with the suffix by default. Done Next devel snapshot * Initial integration of VHDL code generator? Done * Do not include elaborate-net-rework. (Save that for right after the snapshot) Already merged * Fix pr2030767 (long division problem) Done Version 0.9.0 Once we make a 0.9.0 release, all subsequent 0.9.x releases need to remain compatible with each other. For example, vvp output from 0.9.0 must run on 0.9.1. I'm not certain we should require backwards compatibility, but we should certainly encourage it. So we don't want to make a 0.9 release until we are comfortable with the state of the vvp runtime syntax. * We want to include the VHDL target code generator in this release. * Must fix pr2030767. (I think this belongs in the next snapshot) Done * Better handling of versions of the parts of iverilog Done See the Projects page. There may be API changes for modules that we should get implemented before the release. * We want the limited SDF support to work. I'm not sure whether bug number 2070488 needs to be fixed before this release. A proper fix will almost certainly mean changes to the vvp syntax, so if it doesn't get fixed for 0.9, it will probably have to wait for 0.10. * Perhaps we want -gno-specify to be default? Given that SDF support is not likely to be super complete, and may have the above bug lingering, maybe we want specify support to be turned off by default so that users don't encounter it unless they know what they are doing. * Complete the elimination of elaborate_net methods. Done * We want $min(), $max(), $abs(), and the other -2005 math functions fully supported with all their polymorphic twists. Done Technically min(), max() and abs() are only Verilog-A constructs so we could wait for them until we have better VAMS support in a later release. The following needs to be done before the release. Take everything except for $min(), $max() and $abs() and make them always available like in 1364-2005. Make the 1364-2005 functions work as constant functions. I am currently working on this. Decide exactly what we want to do with $min(), $max() and $abs(). Do we keep them as is or do we implement their polymorphic abilities and make them part of standard Verilog or are they only available during VAMS. Is $log only available during VAMS or is this alias also available by default? Done * Add support for installation suffixes This is to allow users (packagers) to install mix versions of Icarus Verilog on a system. The default for 0.9 starting at 0.9.1 should be to turn the suffix off. * Ideally, all priority 6 and above bugs should be killed. Development After 0.9 * Verilog-AMS fleshed out enough that it is usable. * Bring back synthesis. * Verify VPI interface functionality against standard functions and add missing functionality that makes sense for Icarus.